With the increasing use of distributed web services and cloud computing, third-party applications require access to server-hosted resources. Most of these resources are usually protected and require explicit user authorization, after successful user authentication using the resource owner's credentials (typically a username and password). In the traditional client-server authentication model, a client accessing a protected resource on a server presents the resource owner's credentials in order to authenticate and gain access.
The problem is that, in order for these applications to access user data on other sites, they ask for usernames and/or passwords. Not only does this require exposing user passwords to someone else—often the same passwords used for online banking and other sites—it also provides these applications with unlimited access to do as they wish, so that they can do anything, including changing the passwords and lock users out.
It means that the solution must provide the user not only with the confidentiality of his/her credentials but also with the ability to restrict access to a limited subset of the resources they control, to limit access duration, or to limit access to the HTTP methods supported by these resources. The OAuth protocol 1.0, defined in “RFC 5849—The OAuth 1.0 Protocol” provides such a solution, based on a 3-legged model and web-redirections.
OAuth 1.0 is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications, available both for Trusted and Non-Trusted Consumers (Clients). OAuth, as specified, is directly applicable to grant access to resources in REST services, but can also be used for example in SOAP-based web services.
In order for the client to access resources, it first has to obtain permission from the resource owner by means of the OAuth API. This permission is expressed in the form of a token and matching shared-secret. The purpose of the token is, as already explained, to make it unnecessary for the resource owner to share its credentials with the client. Unlike the resource owner credentials, tokens can be issued with a restricted scope and limited lifetime, and revoked independently.
In short, the main purpose of the OAuth protocol is to provide the means for the consumer to gain a valid AccessToken following the interactions that are summarized on FIG. 1, which shows the 3-legged access scenario.
In this 3-legged access mode, there are two tokens with crucial roles:
In the first place, Request Token is used as a reference within the delegated authorization procedures. More concretely, Request Tokens are used by the Client to ask the User to authorize access to the Protected Resources. To do this, the user is redirected to a portal where the user is authenticated and the user authorizes the access to the Protected Resources owned by him. Then, the client receives a verification code and exchanges this code and the User-authorized Request Token, that is recommended to have a limited lifetime, for an Access Token.
Finally, this Access Token is used by the Client to access the APIs on behalf of the User, instead of using the User's credentials (user and password). Access Tokens may limit access to certain APIs or even resources within a given API.
Therefore, step by step, FIG. 1 involves the client 2 sending a request for a Request_token 4 to the Server 3. Steps 5 and 6 provide the Request_token to the client and inform the user 1 about the action and steps 7 and 8 user informs the server that the client is authorized. Then it is redirected 9 to the client and the client obtains an Access_token in steps 10 and 11, thus the authentication 12 is completed. Steps 13, 14, 15 and 16 comes after the authentication, the client access to data on the server on behalf of the user.
There are other authentication methods that make use of different mechanisms. Also, the Short Message Service (SMS) has already been used together with other techniques to send the final user the needed credentials to access resources.
For instance, US patent application publ. US 2010/0100725 A1 discloses a method for providing user authentication. When a user of a website or an enterprise server system wishes to access certain information or perform certain transactions on the website/server, they are asked to enter a user name and password into a user interface (UI). Using a password associated with a particular username can provide for authentication of the user, for example, because the password is typically known only to the user who is registered with the website/server. However, security for remote access to websites and servers can be compromised if passwords are used by those other than the registered user (e.g., by identity thieves).
Current multi-factor authentication techniques include utilizing telephones or mobile devices as a second authentication factor. As an example, when a website user attempts to purchase an item online, the host website can send a short message service (SMS) message (e.g. a text message) to the user's mobile device (e.g., mobile phone). In this example, after receiving the SMS message, the user can reply with an authentication key provided by the website. In this way, for example, an identity thief would need the user's username, password, and designated mobile device in order to complete the authentication.
The main problem, as stated above, is that OAuth protocol is based on Web redirections (HTTP methods). This means that OAuth is appropriate for web applications and in general for usage environments where redirecting the user to a web page for authentication and authorization is an appropriate User Experience. For other environments or applications, such as non-web based applications installed in a mobile handset, the web redirections do not provide an appropriate User Experience, specially the step where the user has to enter his/her credentials in a web as authentication method. Further, for non-web native mobile handset Applications, the web-redirection implies that the Application looses the control of the User flow.